Skip to content

Port #[cfg] to the new attribute parsing infrastructure #143460

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 15, 2025

Conversation

JonathanBrouwer
Copy link
Contributor

@JonathanBrouwer JonathanBrouwer commented Jul 4, 2025

Ports #[cfg] to the new attribute parsing infrastructure for #131229 (comment)

I've split this PR into commits for reviewability, and left some comments to clarify things

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 4, 2025
@petrochenkov
Copy link
Contributor

I don't understand what is the point of this, at high level.
cfg and cfg_attr are a sort of macro attributes, they are not lowered into anything and do not appear in HIR.
I didn't yet hear about any plans to extend the new infra to something beyond inert attributes.

@petrochenkov
Copy link
Contributor

petrochenkov commented Jul 5, 2025

Or is this is going to be only about cfg predicates that live inside cfg or cfg_attr?
Those can indeed occur in some inert attributes too, for example link, in that case they need to be lowered and encoded in metadata.

@JonathanBrouwer
Copy link
Contributor Author

JonathanBrouwer commented Jul 5, 2025

@petrochenkov

@jdonszelmann might be able to explain better, she has been supporting me, but I'll try my best.

We already have some infrastructure for parsing attributes in the early stage, before the HIR, and this is already used for the repr attribute. The long term plan is to completely get rid of rustc_attr/attr/mod.rs, and the cfg attribute uses this so it also needs to be converted to a parsed attribute. I hope the change will be clearer when this PR is ready, it is still very much work in progress. There's a nice amount of code which I should be able to delete when this PR is ready.

Furthermore as you mentioned some attributes like link also need this change, I currently have a PR open for porting link which is blocked on this change.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Jul 6, 2025

☔ The latest upstream changes (presumably #143526) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 6, 2025
@JonathanBrouwer JonathanBrouwer force-pushed the cfg_parser branch 2 times, most recently from 8a1e8fb to 60e69b8 Compare July 7, 2025 07:15
Copy link
Contributor Author

@JonathanBrouwer JonathanBrouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,247 @@
use rustc_ast::{LitKind, MetaItem, MetaItemInner, MetaItemKind, MetaItemLit, NodeId};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is temporarily still needed for the following things: #[doc], #[link], cfg!(), #[cfg_attr].
In the future this file, as well as a few others, should no longer be needed, but making these attributes use the new cfg parser is sadly not easily possible without parsing the entire attributes.

As well as this file, there is also the Cfg type in rustdoc and all errors associated with this file. All in all this PR could have a significantly negative diff (all of this is like ~600 lines of code) if not for this

pub(crate) fn cfg_true(&self, attr: &Attribute, node: NodeId) -> EvalConfigResult {
// We need to run this to do basic validation of the attribute, such as that lits are valid, etc
// FIXME(jdonszelmann) this should not be necessary in the future
match validate_attr::parse_meta(&self.sess.psess, attr) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly this is needed, @jdonszelmann are you aware of this / do you have any plans to fix this?
We're also still parsing all the other attributes using both the old and new parser for this, probably not performance sensitive but a bit weird

pub fn main() {}
pub fn main() {
if cfg!(not()) { }
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error code will not be needed in the future (as wel as many others), but needed a new example for now

/// Whether to emit errors or delay them as a bug
/// For most attributes, the attribute will be parsed again in the `Late` stage and in this case the errors should be delayed
/// But for some, such as `cfg`, the attribute will be removed before the `Late` stage so errors must be emitted
pub emit_errors: bool,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is needed because #[cfg] will not be parsed in the Late stage, so we need to emit all errors/warnings now

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 7, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 7, 2025

jdonszelmann is not on the review rotation at the moment.
They may take a while to respond.

@JonathanBrouwer JonathanBrouwer marked this pull request as ready for review July 7, 2025 07:26
@rustbot
Copy link
Collaborator

rustbot commented Jul 7, 2025

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

|
LL | #[cfg(false)]
| ^^^^^^^^^^^^^
| ^^^^^
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a small change here, this error will now always point to the exact part of the cfg attribute that makes the attribute false

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 8, 2025
@bors
Copy link
Collaborator

bors commented Jul 10, 2025

☔ The latest upstream changes (presumably #143731) made this pull request unmergeable. Please resolve the merge conflicts.

features: Option<&'sess Features>,
emit_errors: bool,
parse_fn: fn(cx: &mut AcceptContext<'_, '_, Early>, item: &ArgParser<'_>) -> T,
template: &AttributeTemplate,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdonszelmann Instead of calling the general attribute parser I now call this function. This function takes a parse_fn and a template (sadly needed :c) and calls that specific parser. I think this is approximately what you wanted right?

@rustbot ready

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, in fact I think we can migrate more to this system. nice!

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 11, 2025
@bors
Copy link
Collaborator

bors commented Jul 14, 2025

☔ The latest upstream changes (presumably #143779) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 14, 2025
@JonathanBrouwer
Copy link
Contributor Author

JonathanBrouwer commented Jul 15, 2025

@rustbot author
I think I know what I did wrong

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 15, 2025
@@ -13,4 +13,8 @@ pub fn expected() {}
//~^ WARNING unexpected `cfg` condition name
pub fn unexpected() {}

#[cfg(target(os = "windows", architecture = "arm"))]
//~^ WARNING unexpected `cfg` condition name
Copy link
Contributor Author

@JonathanBrouwer JonathanBrouwer Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem was that I implemented evaluation of all() and any() as short-circuiting.
This is not correct because during evaluation, sometimes lints are emitted (see https://github.com/JonathanBrouwer/rust/blob/7a7c74ad89df9f87824fa17fbbe0448d9ab6f7cc/compiler/rustc_attr_parsing/src/attributes/cfg.rs#L233). We should emit these lints, even after an earlier condition already failed.

The only test that tests this apparently is the unexpected test above this comment, which happens to only test this for non-linux targets. I added a second test unexpected2 to also test this on linux targets.

@rustbot ready
r? @jdonszelmann

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a test for this that's not windows only?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one above unexpected, would work for everything but linux
I added one that works for everything but linux
I suppose I could've just use false but whatever :P

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 15, 2025

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

@jdonszelmann
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 15, 2025

📌 Commit 7a7c74a has been approved by jdonszelmann

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Jul 15, 2025

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 15, 2025
@bors
Copy link
Collaborator

bors commented Jul 15, 2025

⌛ Testing commit 7a7c74a with merge a9fb610...

@bors
Copy link
Collaborator

bors commented Jul 15, 2025

☀️ Test successful - checks-actions
Approved by: jdonszelmann
Pushing a9fb610 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 15, 2025
@bors bors merged commit a9fb610 into rust-lang:master Jul 15, 2025
12 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 15, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 7f2065a (parent) -> a9fb610 (this PR)

Test differences

Show 26 test diffs

26 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard a9fb6103b05c6ad6eee6bed4c0bb5a2e8e1024c6 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. aarch64-apple: 3820.7s -> 5959.4s (56.0%)
  2. dist-aarch64-linux: 8199.1s -> 5748.6s (-29.9%)
  3. x86_64-apple-1: 10077.7s -> 7094.5s (-29.6%)
  4. aarch64-msvc-2: 4977.3s -> 6371.3s (28.0%)
  5. pr-check-2: 2117.9s -> 2633.1s (24.3%)
  6. i686-gnu-2: 5332.5s -> 6164.7s (15.6%)
  7. i686-gnu-nopt-1: 7109.8s -> 8100.8s (13.9%)
  8. x86_64-gnu-llvm-20-1: 3286.7s -> 3723.8s (13.3%)
  9. i686-gnu-1: 7307.2s -> 8217.8s (12.5%)
  10. x86_64-gnu-distcheck: 7940.2s -> 8807.9s (10.9%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants